Filemaker V9 WinXP
I have created a calculation for a web object. When I show the result as a
text field it shows:
Girl by
Gabriel Metsu
17th Century Baroque Fashion, 1636-1664
Exactly as expected. When I now tie this field to a web object it returns:
Loading: "%3CHTML%3E%20%3CIMG%20SCRmode%5C166x_10.jpg%22%20height (just
truncated here, but it just goes on like that)
What happens?
Keep well, Ursus
On Sep 16, 3:21 am, "Ursus"
> Filemaker V9 WinXP
>
> I have created a calculation for a web object. When I show the result as a
> text field it shows:
>
>
Girl by
> Gabriel Metsu
>
> 17th Century Baroque Fashion, 1636-1664
>
> Exactly as expected. When I now tie this field to a web object it returns:
>
> Loading: "%3CHTML%3E%20%3CIMG%20SCRmode%5C166x_10.jpg%22%20height (just
> truncated here, but it just goes on like that)
>
> What happens?
>
> Keep well, Ursus
Filemaker thinks the text field contains a URI that points to the html
to display, not the actual html.
So its URI encoding the text field (because < > and spaces etc aren't
legal uri characters) and then trying to load from it. Which of course
is no good.
You need to use, for example, the data: URI scheme to put immediate
data into a URI.
http://en.wikipedia.org/wiki/Data:_URI_scheme
Note that the maximum URI length is typically quite small, so you can
only put a bit of data into one. I do know filemaker supports the
data: URI scheme, but no idea what the limit on URI length is for
filemaker. (note that URI encoding can easily be a few times the
length of the original data during uri encoding as spaces and other
illegal uri characters like "<" and ">" all get converted to %20, %3C,
etc.
If you need more length than it supports, you can export the field to
a file, and then load it in the web viewer with a file: URI. Maybe
filemaker supports pulling data right from a field as well (instead of
treating the field as a URI via a checkbox setting?? I don't have
FM8,5+ handy to check.)
-cheers,
Dave
-cheers,
dave
On Sep 16, 1:35 pm, d-42
> On Sep 16, 3:21 am, "Ursus"
>
>
>
> > Filemaker V9 WinXP
>
> > I have created a calculation for a web object. When I show the result as a
> > text field it shows:
Just an update to my previous post:
FM 9's help notes that Filemaker 8.5 does not work with the data: URI
under Windows.
I suspect the reason it wasn't supported in 8.5 under windows is that
Filemaker actually uses the platforms native rendering engine. And on
Windows that is Internet Explorer. And Internet Explorer doesn't
support the data:URI scheme.
Now this is where things get interesting:
However, as of Filemaker 9, the data: URI scheme -is- supported, on
windows, even though IE7 still doesn't natively support the uri.
data:, and filemaker still uses IE7 as its web renderer.
I'm not surprised they 'fixed' this. Using a field as an html data
source is about the most obvious feature one could expect, and having
it on the mac but not on the PC is beyond annoying.
So, now, the data: uri is supported on windows.
But -how- exactly does this work?
Well, it turns out when you use a data: uri in filemaker 9 on windows,
filemaker evidently pre-parses the URI, and if its a data: uri, it
creates a temporary file with the actual data, and then redirects the
IE based web renderer to the temp file.
Neat.
Overall its a clever workaround to overcome one of IEs many
shortcomings.
There is a minor security issue present though; as anything displayed
in a web viewer has to be stored in a local file first. If one were to
display a credit card number for example in the web viewer using the
about: URI to acheive some unique CSS / formatting effect, that item
will also be dumped to a local file, which may persist and be easily
recoverable long after the filemaker session is closed.
The good news is that filemaker actually does remove those temp files
after it exits. The bad news is that presumes filemaker exitted
properly, which isn't always the case, so temps might get left behind
from time to time. Additionally, files can often be retrieved
trivially with an 'undelete' program.
Like I said, its a pretty minor security issue. Someone would have to
steal the PC, boot it up and then try and recover deleted files - so
its not a major hole.
I still I tend to like to be aware of things like this though.
After all, one would normally expect data: URI's not to result in a
file being written at all.
-cheers
Dave
"d-42"
news:1190156015.578884.316390@v23g2000prn.googlegroups.com.. .
> On Sep 16, 1:35 pm, d-42
>> On Sep 16, 3:21 am, "Ursus"
>>
>>
>>
>> > Filemaker V9 WinXP
>>
>> > I have created a calculation for a web object. When I show the result
>> > as a
>> > text field it shows:
>
> Just an update to my previous post:
>
> FM 9's help notes that Filemaker 8.5 does not work with the data: URI
> under Windows.
>
> I suspect the reason it wasn't supported in 8.5 under windows is that
> Filemaker actually uses the platforms native rendering engine. And on
> Windows that is Internet Explorer. And Internet Explorer doesn't
> support the data:URI scheme.
>
> Now this is where things get interesting:
>
> However, as of Filemaker 9, the data: URI scheme -is- supported, on
> windows, even though IE7 still doesn't natively support the uri.
> data:, and filemaker still uses IE7 as its web renderer.
>
> I'm not surprised they 'fixed' this. Using a field as an html data
> source is about the most obvious feature one could expect, and having
> it on the mac but not on the PC is beyond annoying.
>
> So, now, the data: uri is supported on windows.
>
> But -how- exactly does this work?
>
> Well, it turns out when you use a data: uri in filemaker 9 on windows,
> filemaker evidently pre-parses the URI, and if its a data: uri, it
> creates a temporary file with the actual data, and then redirects the
> IE based web renderer to the temp file.
>
> Neat.
>
> Overall its a clever workaround to overcome one of IEs many
> shortcomings.
>
> There is a minor security issue present though; as anything displayed
> in a web viewer has to be stored in a local file first. If one were to
> display a credit card number for example in the web viewer using the
> about: URI to acheive some unique CSS / formatting effect, that item
> will also be dumped to a local file, which may persist and be easily
> recoverable long after the filemaker session is closed.
>
> The good news is that filemaker actually does remove those temp files
> after it exits. The bad news is that presumes filemaker exitted
> properly, which isn't always the case, so temps might get left behind
> from time to time. Additionally, files can often be retrieved
> trivially with an 'undelete' program.
>
> Like I said, its a pretty minor security issue. Someone would have to
> steal the PC, boot it up and then try and recover deleted files - so
> its not a major hole.
>
> I still I tend to like to be aware of things like this though.
>
> After all, one would normally expect data: URI's not to result in a
> file being written at all.
>
> -cheers
> Dave
>
Thanks Dave, for your long update. But how does this affect my original
question? WinXP and FMP v9 adv. I have a calculation that returns valid
HTML. But when I use this calculation for the Webviewer it simply returns
loading: : "%3CHTML%3E%20%3CIMG%20SCRmode%5C166x etc etc. (Should be
wrote:
> "d-42"
>
>
>
> > On Sep 16, 1:35 pm, d-42
> >> On Sep 16, 3:21 am, "Ursus"
>
> >> > Filemaker V9 WinXP
>
> >> > I have created a calculation for a web object. When I show the result
> >> > as a
> >> > text field it shows:
>
> > Just an update to my previous post:
>
> > FM 9's help notes that Filemaker 8.5 does not work with the data: URI
> > under Windows.
>
> > I suspect the reason it wasn't supported in 8.5 under windows is that
> > Filemaker actually uses the platforms native rendering engine. And on
> > Windows that is Internet Explorer. And Internet Explorer doesn't
> > support the data:URI scheme.
>
> > Now this is where things get interesting:
>
> > However, as of Filemaker 9, the data: URI scheme -is- supported, on
> > windows, even though IE7 still doesn't natively support the uri.
> > data:, and filemaker still uses IE7 as its web renderer.
>
> > I'm not surprised they 'fixed' this. Using a field as an html data
> > source is about the most obvious feature one could expect, and having
> > it on the mac but not on the PC is beyond annoying.
>
> > So, now, the data: uri is supported on windows.
>
> > But -how- exactly does this work?
>
> > Well, it turns out when you use a data: uri in filemaker 9 on windows,
> > filemaker evidently pre-parses the URI, and if its a data: uri, it
> > creates a temporary file with the actual data, and then redirects the
> > IE based web renderer to the temp file.
>
> > Neat.
>
> > Overall its a clever workaround to overcome one of IEs many
> > shortcomings.
>
> > There is a minor security issue present though; as anything displayed
> > in a web viewer has to be stored in a local file first. If one were to
> > display a credit card number for example in the web viewer using the
> > about: URI to acheive some unique CSS / formatting effect, that item
> > will also be dumped to a local file, which may persist and be easily
> > recoverable long after the filemaker session is closed.
>
> > The good news is that filemaker actually does remove those temp files
> > after it exits. The bad news is that presumes filemaker exitted
> > properly, which isn't always the case, so temps might get left behind
> > from time to time. Additionally, files can often be retrieved
> > trivially with an 'undelete' program.
>
> > Like I said, its a pretty minor security issue. Someone would have to
> > steal the PC, boot it up and then try and recover deleted files - so
> > its not a major hole.
>
> > I still I tend to like to be aware of things like this though.
>
> > After all, one would normally expect data: URI's not to result in a
> > file being written at all.
>
> > -cheers
> > Dave
>
> Thanks Dave, for your long update. But how does this affect my original
> question? WinXP and FMP v9 adv. I have a calculation that returns valid
> HTML. But when I use this calculation for the Webviewer it simply returns
> loading: : "%3CHTML%3E%20%3CIMG%20SCRmode%5C166x etc etc. (Should be
> Index |
Impressum |
Datenschutz |
XODOX